Plasma Cash における手数料の徴収方法
m0t0k1ch1.icon Plasma Cash に関する議論の中から手数料の徴収方法に関する投稿をピックアップ
---.icon
首脳陣の提案
m0t0k1ch1.icon オペレータがどのように手数料を徴収するかについて、kfichter がいくつか可能性を提案している
1. Fees are paid as some small Plasma Cash coin. Users still don’t need to check the entire chain, but this is (potentially) poor UX if we require users to hold a cache of low value coins. However, this is the most “Plasma Cash”-like approach.
2. Fees are paid as a “fee token.” Fee Tokens are indivisible/non-mergeable tokens that can be validated in the same manner as Plasma Cash (imagine ERC721). Transactions always cost 1 FT. This is similar to (1), except that FT value is determined by some market. Some assumptions are being made there that FTs will typically flow to operators, who will sell them back to users to keep the system running. Wouldn’t want any users to hoard FTs to stall the system. Has the unfortunate side-effect that transactions can’t be given priority based on fee. I need to consider the economics of this one more thoroughly.
3. Fees are paid in some fungible coin/token alongside the Plasma Cash coins. I couldn’t find a way to make this desirable because you’d inevitably have to verify the entire set of fee transactions. You might be able to separate this from the Plasma Cash chain by creating a “fee chain” where each fee tx necessarily references some Plasma Cash txid. A lot of issues with this construction, not considering complexity.
kfichter:
1. 手数料は少量の Plasma Cash コインで支払われる
ユーザーはチェーン全体をチェックする必要はないが、ユーザーに少量のコインを保持することを要求するのは UX としてよろしくない
が、これは Plasma Cash 的なアプローチと言える
2. 手数料は「手数料トークン」で支払われる
手数料トークンは、Plasma Cash と同様の方法で検証される分割・結合が不可能なトークン
イメージは ERC721
トランザクションは常に 1 FT(Fee Token)を必要とする
これは 1. に似ているが、FT の価値は市場によって決定されるという点で異なる
通常、FT はオペレータに流れるが、システムの稼働を維持するためにオペレータは FT をユーザーに売却する、など、いくつかの仮定はある
システムを行き詰まらせるために FT をため込みたいユーザーはいないと考えられる
手数料に基づいてトランザクションに優先順位を与えられないという不幸な副作用がある
この提案に関する経済についてはより深く検討する必要がある
3. 手数料は Plasma Cash コインと並行して存在する fungible なトークンで支払われる
この提案を価値あるものにするのは難しい
必然的に手数料トランザクション全体を検証する必要が出てきてしまうから
Plasma Cash チェーンとは別の手数料チェーンをつくって、切り分けることもできる
各手数料トランザクションは Plasma Cash の txid を参照する必要がある
複雑なことは考えていないので、これを構築するにあたってはたくさんの課題がある
m0t0k1ch1.icon 1. は、素直に Plasma Cash コインでやりきるパターン
m0t0k1ch1.icon 2. は、Plasma Cash コインとは別の non-fungible なトークンを使うパターン
m0t0k1ch1.icon 3. は、Plasma Cash コインとは別の fungible なトークンを使うパターン
m0t0k1ch1.icon vbuterin も以下のような提案をしている
Every transaction must include a “total fee” in its body. The Plasma chain operator only accepts transactions if their total fee exceeds that of their parent tx, and prioritizes by total_fee - parent_total_fee. When a coin is withdrawn, the amount that can be withdrawn is equal to deposit_size - total_fee.
vbuterin:全てのトランザクションはその中に「合計手数料」を含まなければならない。オペレータは合計手数料が親トランザクションのそれを上回っているトランザクションのみを受諾し、「合計手数料 - 親トランザクションの時点での合計手数料」で優先順位をつける。コインが引き出される際、引き出すことが可能な量は「デポジット量 - 合計手数料」となる。
m0t0k1ch1.icon トランザクションが発生する度に蓄積して exit 時にまとめて引き出し額から差し引くパターン
m0t0k1ch1.icon これに対して kfichter が以下のように続けている
One potential complexity I see with this construction is the realization of fees. Operators could “exit” on a fee by referencing a specific coin. We’d have to also maintain a mapping on the root chain of coin IDs to total fee claimed. The owner of that coin could then challenge if they prove that latest total_fee - total_fee_claimed is less than sum of all fees claimed on that coin by the operator.
kfichter:1 つ複雑になってしまう可能性があると思うのは、手数料の引き出し。オペレータは特定のコインに関する手数料を引き出すことができるとなると、親チェーンでコイン ID と引き出し済み手数料のマッピングも管理しなければならない。コインの所有者は、最新の「合計手数料 - 引き出し済み手数料」が、そのコインについてオペレータによって引き出し申請された手数料の合計より少ないことを証明することで challenge ができる。
m0t0k1ch1.icon オペレータの手数料引き出しに関しても考えることあるよねという話
m0t0k1ch1.icon 手数料残高を上回る額を引き出そうとした際の challenge など
This works for a single operator but becomes more complex if the chain is operated in some way that different operators claim fees individually.
kfichter:これはオペレータが 1 人の場合は機能するが、複数のオペレータがそれぞれ手数料を exit したくなるような方法で子チェーンが運用されている場合はより複雑になる。
Another possibility is accepting a fee from a separate “fee balance” on the root chain. You’d deposit X ETH (or whatever) into the root contract specifically to be used for fees. Each Plasma Cash tx would specify a fee. Users can then only ever withdraw the fee balance minus the total fees they’ve specified on each transaction. This is never more than what they’ve deposited initially.
kfichter:親チェーン上の「手数料残高」から手数料を受け付けることができるかもしれない。例えば、親チェーンのコントラクトに手数料として使用するための X ETH をデポジットする。子チェーンのトランザクションには手数料を指定する。ユーザーは「手数料残高 - 各トランザクションで指定した手数料の合計」を引き出すことができる。各トランザクションで指定した手数料の合計は、初期にデポジットした量を決して超えることはない。
m0t0k1ch1.icon ユーザーがあらかじめ手数料をデポジットしておくパターン
A withdrawal from the fee balance would be followed by a challenge period where anyone can prove that the total fees specified by the user is greater than the total fees the user claims to have specified. Operators are the only ones harmed if a user tries to withdraw more than they’re allowed to withdraw because withdrawals can never exceed the current fee balance. Operators already have to validate the entire chain, so they’d have the information required to challenge. Operators just wouldn’t accept a transaction if the user tries to specify a fee that’s greater than their current available fee balance.
kfichter:手数料残高からの引き出しは、以下のような challenge 期間を経由して行われる。challenge 期間においては、ユーザーによって指定された合計手数料がユーザーが指定したと主張する合計手数料を上回っていることを誰でも証明できる(?)。ユーザーが自身に引き出し許可された量を上回る量を引き出そうとしたときに損害を被るのはオペレータだけ。なぜなら、引き出しはそのときの手数料残高を決して上回ってはいけないから。オペレータは常にチェーン全体を検証する必要があるので、challege に必要な情報を持っている。オペレータは、ユーザーがそのとき使用可能な手数料残高を上回る手数料を指定しようとした場合、トランザクションを受諾しないだけでよい。
m0t0k1ch1.icon danrobinson も以下のような提案をしている
・Plasma chain operator charges for deposits, then executes transactions for free, using conventional methods to prevent denial of service attacks. This doesn’t really change the trust model because the chain operator can censor whatever they want anyway.
・Plasma chain operator also runs a “change service” for which they maintain many very-small-denomination coins (as @kfichter suggested way above); the transaction fee is withheld as part of this.
オペレータはデポジットに対して請求を行い、サービス拒否攻撃を防ぐために従来の方法を用いつつ、トランザクションは無料で実行する。これによって信頼モデルが変わることはない。なぜなら、オペレータは何でも検閲できるから。
オペレータは「両替サービス」も提供する。これは、非常に小さな単位のコイン達をメンテするためのもの。トランザクション手数料はこのサービス利用時に差し引かれる。
m0t0k1ch1.icon 1 つ目の提案について、ユーザーのデポジットに対して手数料を請求するっていうのはなんとなく理解できる(子チェーンへの入場料的なものだと考えられる)が、後半部分の意図がいまいち理解できない
---.icon
ペイメントチャネルの利用
m0t0k1ch1.icon vbuterin が以下のように軽く言及している
Another missing alternative here is transaction fees through channel payments.
m0t0k1ch1.icon これに対して danrobinson が以下のようにコメントしている
I think payment channels and cross-chain atomic swaps are pretty difficult on Plasma Cash (even if the spending conditions supported time locks and hash locks) because the channel operator has the power to both censor transactions and withhold data (i.e. a revealed preimage). But I guess you could use a regular ETH payment channel and forget atomicity because the fee amounts are so small.
Plasma Cash において、ペイメントチャネルやクロスチェーンなアトミックスワップはかなり難しいと思う(タイムロックやハッシュロックがサポートされていたとしても)。なぜなら、オペレータはトランザクションを検閲する力とデータ(すなわち、公開されたプレイメージ)を withhold する力の両方を持っているから。しかし、手数料の量はとても小さいので、通常の ETH ペイメントチャネルを使ったり、atomicity を無視したりすることはできるかもしれない。
m0t0k1ch1.icon ところどころ意図が読めない部分はあるが、「オペレータがトランザクション実行に対して強い力を持っている子チェーンでは、そもそもペイメントチャネルやアトミックスワップを機能させることは難しい」ということ?
m0t0k1ch1.icon 最後に言ってる atomicity が「子チェーンのトランザクションとそれに紐づく何らかの手数料支払い処理」の atomicity のこと?であれば、彼が想定してるのは、その何らかの手数料支払い処理をペイメントチャネルでやって atomicity を保つということであり、確かにそれはかなり厳しい(というかそもそも複雑過ぎる)と思う
---.icon
m0t0k1ch1.icon memo
ユーザーごとにあらかじめ手数料をデポジットさせておく kfichter の提案が妥当なように思えるが、親チェーンと子チェーンのデータ連携が増える(子チェーンのトランザクションを捌くために都度親チェーンのデータを確認しなければならない)のはデメリットだと思う(セキュリティホールの温床になりうる)
そう考えると、確かに vbuterin の提案がほぼ子チェーン完結できるのでシンプルではある(極少量のコインに関するトランザクション量に限りが出てきそうだが、そもそも Plasma Cash においてそんなコインをデポジットするのは不適切だし、まずは複数オペレータ不可でもいいから実現可能なパターンの MVP 化が重要なように思う)